Method and system for inter and intra agency communication, tracking and coordination

ABSTRACT

A method is disclosed. A data set including: (a) identifiers of a set of incidents occurring within a defined geographic region to which at least one service provider responded during a first time period and (b) address data identifying a location within the geographic region of each said incident of the set is retrieved over a network. An instruction to generate a heat map of the incidents occurring within the geographic region during the first time period is received from a user via a user interface generated to a display device. In response to the instruction to generate the heat map, the address data is converted to GPS data. A heat map of an aerial view of the geographic region based on the GPS data is generated. The heat map is displayed to the display device in a user interface.

CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY CLAIM

The present application is a Continuation of U.S. patent applicationSer. No. 17/007,855 filed Aug. 31, 2020, which claims priority from U.S.Provisional Application No. 62/894,500, filed Aug. 30, 2019. The presentapplication is a continuation-in-part of U.S. application Ser. No.16/917,182, filed Jun. 30, 2020, which is a continuation of U.S.application Ser. No. 16/231,801, filed Dec. 24, 2018, which claimspriority from U.S. Provisional Application No. 62/609,942, filed Dec.22, 2017 and is a continuation-in-part of U.S. application Ser. No.14/213,995, filed Mar. 14, 2014, which claims priority from U.S.Provisional Application No. 61/792,517, filed Mar. 15, 2013, and U.S.Provisional Application No. 61/905,701, filed Nov. 18, 2013. All of theaforementioned applications are hereby incorporated by reference intheir entireties as if fully set forth herein.

BACKGROUND OF THE INVENTION

Coordination among different first-responder agencies, such as police,ambulance and fire, within a community and among agencies in differentcommunities is critical to the well-being of such community(ies).Consequently, a system and/or method that allows visual tracking, inreal-time or as near to real-time as is technologically possible, of thelocation, velocity and bearing of emergency vehicles would bebeneficial. Moreover, a system and/or method that allows a comprehensivevisual review of coordination efforts after an emergency event ofemergency vehicles responding to such event would be likewisebeneficial.

Moreover, due to the market in Public Safety, previous approaches havebeen single solutions provided by each vendor and naming conventionsthat have no standard associated and use at each customer location.Several computer-aided dispatch (CAD) or records management systems allutilize different mechanisms specific to their systems only and rarelyif at all share between disparate systems. As such, each customerutilizes naming conventions specific to their agency or application.

The constraint and limitations of previous approaches are related to aclosed product approach that is only a single solution for that onesoftware company, or any installation that have that same software.Previous approach is based on a vendor market to customers they provideservices to without sharing, no standard industry naming conventionswhich are adjustable by customer for each individual need.

In emergency services, mutual aid is an agreement among emergencyresponders to lend assistance across jurisdictional boundaries. This mayoccur due to an emergency response that exceeds local resources, such asa disaster or a multiple-alarm fire. Mutual aid may be ad hoc, requestedonly when such an emergency occurs. It may also be a formal standingagreement for cooperative emergency management on a continuing basis,such as ensuring that resources are dispatched from the nearest firestation, regardless of which side of the jurisdictional boundary theincident is on.

Prior to the present invention, Public Safety Answering Points (PSAPs)would have to place a phone call to another PSAP when requesting mutualaid. The phone calls incur delays and can result in miscommunication orincomplete communication which could be detrimental to the firstresponders requested to assist on the incident. Additionally, the calldetails must be relayed to the first responders over the radio which issubject to background noise, interference and/or lost transmissions.

The previous approaches have several disadvantages:

Phone calls between PSAPs incur delays in obtaining critical incidentinformation for first responders.

Radio transmissions can be garbled, missed or lost, which also can bedetrimental to first responders.

BRIEF DESCRIPTION OF THE DRAWING

Preferred and alternative examples of the present invention aredescribed in detail below with reference to the following drawingfigures:

FIG. 1 is a schematic view of an exemplary operating environment inwhich an embodiment of the invention can be implemented;

FIG. 2 is a functional block diagram of an exemplary operatingenvironment in which an embodiment of the invention can be implemented;

FIGS. 3-5 illustrates processes according to one or more embodiments ofthe invention;

FIGS. 6-33 are screenshots illustrating functionality of one or moreembodiments of the invention;

FIGS. 34-36 are screenshots illustrating functionality of a dynamictranslation table according to an embodiment of the invention;

FIGS. 37-40 are screenshots illustrating functionality of heat mapgeneration according to an embodiment of the invention; and

FIGS.41A and 41B-43 are screenshots illustrating functionality of amutual-aid according to an embodiment of the invention.

DETAILED DESCRIPTION

This patent application is intended to describe one or more embodimentsof the present invention. It is to be understood that the use ofabsolute terms, such as “must,” “will,” and the like, as well asspecific quantities, is to be construed as being applicable to one ormore of such embodiments, but not necessarily to all such embodiments.As such, embodiments of the invention may omit, or include amodification of, one or more features or functionalities described inthe context of such absolute terms.

FIG. 1 illustrates an example of a computing system environment 100 inwhich an embodiment of the invention may be implemented. The computingsystem environment 100, as illustrated, is an example of a suitablecomputing environment; however, it is appreciated that otherenvironments, systems, and devices may be used to implement variousembodiments of the invention as described in more detail below.

Embodiments of the invention are operational with numerousgeneral-purpose or special purpose computing system environments orconfigurations. Examples of well-known computing systems, environments,and/or configurations that may be suitable for use with embodiments ofthe invention include, but are not limited to, personal computers,server computers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set-top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers,distributed computing environments that include any of the above systemsor devices, and the like.

Embodiments of the invention may be described in the general context ofcomputer-executable instructions, such as program modules being executedby a computer. Generally, program modules include routines, programs,objects, components, data structures, etc. that perform particular tasksor implement particular abstract data types. Embodiments of theinvention may also be practiced in distributed-computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices. Additionally,the entity that may implement, or otherwise provide the ability toimplement, elements of embodiments of the invention may be referred toherein as an “administrator.”

With reference to FIG. 1, an exemplary system for implementing anembodiment of the invention includes a computing device, such ascomputing device 100. The computing device 100 typically includes atleast one processing unit 102 and memory 104.

Depending on the exact configuration and type of computing device,memory 104 may be volatile (such as random-access memory (RAM)),nonvolatile (such as read-only memory (ROM), flash memory, etc.) or somecombination of the two. This most basic configuration is illustrated inFIG. 1 by dashed line 106.

Additionally, the device 100 may have additional features, aspects, andfunctionality. For example, the device 100 may include additionalstorage (removable and/or non-removable) which may take the form of, butis not limited to, magnetic or optical disks or tapes. Such additionalstorage is illustrated in FIG. 1 by removable storage 108 andnon-removable storage 110. Computer storage media includes volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Memory104, removable storage 108 and non-removable storage 110 are allexamples of computer storage media. Computer storage media includes, butis not limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium which can be used tostore the desired information and which can be accessed by device 100.Any such computer storage media may be part of device 100.

The device 100 may also include a communications connection 112 thatallows the device to communicate with other devices. The communicationsconnection 112 is an example of communication media. Communication mediatypically embodies computer-readable instructions, data structures,program modules or other data in a modulated data signal such as acarrier wave or other transport mechanism and includes any informationdelivery media. The term “modulated data signal” means a signal that hasone or more of its characteristics set or changed in such a manner as toencode information in the signal. By way of example, the communicationmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, radio-frequency (RF),infrared and other wireless media. The term computer-readable media asused herein includes both storage media and communication media.

The device 100 may also have an input device 114 such as keyboard,mouse, pen, voice-input device, touch-input device, etc. Further, anoutput device 116 such as a display, speakers, printer, etc. may also beincluded. Additional input devices 114 and output devices 116 may beincluded depending on a desired functionality of the device 100.

According to one or more embodiments, the combination of software orcomputer-executable instructions with a computer-readable medium resultsin the creation of a machine or apparatus. Similarly, the execution ofsoftware or computer-executable instructions by a processing deviceresults in the creation of a machine or apparatus, which may bedistinguishable from the processing device, itself, according to anembodiment.

Correspondingly, it is to be understood that a computer-readable mediumis transformed by storing software or computer-executable instructionsthereon. Likewise, a processing device is transformed in the course ofexecuting software or computer-executable instructions. Additionally, itis to be understood that a first set of data input to a processingdevice during, or otherwise in association with, the execution ofsoftware or computer-executable instructions by the processing device istransformed into a second set of data as a consequence of suchexecution. This second data set may subsequently be stored, displayed,or otherwise communicated. Such transformation, alluded to in each ofthe above examples, may be a consequence of, or otherwise involve, thephysical alteration of portions of a computer-readable medium. Suchtransformation, alluded to in each of the above examples, may also be aconsequence of, or otherwise involve, the physical alteration of, forexample, the states of registers and/or counters associated with aprocessing device during execution of software or computer-executableinstructions by the processing device.

As used herein, a process that is performed “automatically” may meanthat the process is performed as a result of machine-executedinstructions and does not, other than the establishment of userpreferences, require manual effort.

Referring now to FIG. 2, an embodiment of the present invention may takethe form, and/or may be implemented using one or more elements, of anexemplary computer network system 200. The system 200 includes anelectronic client device 210, such as a personal computer orworkstation, tablet or smart phone, that is linked via a communicationmedium, such as a network 220 (e.g., the Internet), to an electronicdevice or system, such as a server 230. The server 230 may further becoupled, or otherwise have access, to a database 240 and a computersystem 260. Although the embodiment illustrated in FIG. 2 includes oneserver 230 coupled to one client device 210 via the network 220, itshould be recognized that embodiments of the invention may beimplemented using one or more such client devices coupled to one or moresuch servers.

The client device 210 and the server 230 may include all or fewer thanall of the features associated with the device 100 illustrated in anddiscussed with reference to FIG. 1. The client device 210 includes or isotherwise coupled to a computer screen or display 250. The client device210 may be used for various purposes such as network- andlocal-computing processes.

The client device 210 is linked via the network 220 to server 230 sothat computer programs, such as, for example, a browser, running on theclient device 210 can cooperate in two-way communication with server230. The server 230 may be coupled to database 240 to retrieveinformation therefrom and to store information thereto. Database 240 mayhave stored therein data (not shown) that can be used by the server 230and/or client device 210 to enable performance of various aspects ofembodiments of the invention. The data stored in database 240 mayinclude, for example, satellite and other aerial map data, includinggeographic information system (GIS)-layer data, automated vehiclelocating (AVL) data and keyhole markup language (KML) data.Additionally, the server 230 may be coupled to the computer system 260in a manner allowing the server to delegate certain processing functionsto the computer system. In an embodiment, most or all of thefunctionality described herein may be implemented in a desktopapplication 270 that may include one or more executable modules. In anembodiment, the client device 210 may bypass network 220 and communicatedirectly with computer system 260.

Still referring to FIG. 2, and in operation according to an embodimentof the invention, a user (not shown) of the client device 210 desiringto track or review the performance of one or more emergency-responsevehicles may invoke the desktop application 270. Alternatively, the usermay invoke a browser running on the client device 210 to access webcontent, which may, but need not, be served by the server 230.Specifically, by employing an appropriate uniform resource locator (URL)in a known manner, the user may navigate to a website hosted by theserver 230.

FIG. 3 illustrates a process 300, according to an embodiment of theinvention, for tracking a set of at least one emergency serviceprovider. The process 300 is illustrated as a set of operations shown asdiscrete blocks. One or more steps of the process 300 may be implementedin any suitable hardware, software, including instructions embodiedwithin components, firmware, or combination thereof. The order in whichthe operations associated with the process 300 are described is not tobe necessarily construed as a limitation.

At a block 310, an electronic history is compiled. The electronichistory includes at least one identifier of a service provider and GPSdata identifying the geographic location of each service provider ateach time interval within a time period. For example, the client device210, server 230 and/or computer system 260 may regularly (e.g., everyfive seconds or other predetermined time interval) receive, via network220 or other conventional means, AVL data from transmitters in a set ofemergency response vehicles and correlate this data with respectiveidentifiers of these response vehicles that are stored in database 240and/or a memory device associated with client device 210. Such data willtypically take the form of a latitude/longitude position of the responsevehicle and the time at which such vehicle is in such position.Consequently, the electronic history that this correlative activityyields is configured to enable a processing device to determine thegeographic location of a given response vehicle at, for example,five-second intervals within a time period of interest.

At a block 320, the electronic history is stored in a memory device. Forexample, once the position data has been correlated with the serviceprovider identifiers to yield the electronic history, such history isstored in the database 240, for example.

At a block 330, a user interface is generated to a display device withinwhich is displayed a first identifier of a first service provider of theset of at least one service provider. For example, and referring to FIG.6, the client device 210 may generate to the display 250 a menu 600populated with user-selectable identifiers 610 of each response vehiclefor which viewable tracking is available. For each identifier 610, themenu 600 may further identify the agency type 620 of the associatedvehicle. Alternatively, the user interface may include a data entryfield into which the user may enter, in a conventional manner, anidentifier of a response vehicle for which viewable tracking isavailable.

At a block 340, a selection of the first service-provider identifier isreceived from a user via the user interface. For example, and againreferring to FIG. 6, using a conventional pointer device (not shown),the user may select an identifier 610 of a response vehicle that theuser wishes to track. Additionally, the user may select from the userinterface a particular time period of interest (e.g., one or more days,one or more hours during a particular day, etc.), the activity of theselected response vehicle during which the user is interested in seeing.In an embodiment, this user selection of vehicle identifier and timeperiod of interest may be transmitted to the server 230.

At a block 350, in response to the selection of the firstservice-provider identifier, an aerial view of a geographic regionwithin which the first service provider was located during the timeperiod is generated to a display device. For example, upon receiving aselection of identifier 610 and, consequently, a selection of a responsevehicle of interest, the client device 210 may access the database 240,or other memory device, in which the electronic history is stored. Fromthe electronic history, the client device 210 can determine thegeographic region(s) in which the selected response vehicle was locatedduring the selected time period of interest. Subsequently, the clientdevice 210 can, in a conventional manner, generate to display 250 arendering of the determined geographic region(s) using aerial map data,for example, that may be stored in database 240 or on the client deviceitself

At a block 360, at least one icon representing the first serviceprovider at the geographic location corresponding to at least one timeinterval of the set of time intervals is displayed in the aerial view.For example, in the aerial view 700 illustrated in FIG. 7, depending onthe duration of the user-selected time period of interest, one or moreicons 710 illustrating the activity of the selected response vehicle aresuperimposed on the rendered geographic region 720 determined at block350. In the illustrated example, a comparatively lengthy time period ofinterest has been selected by the user, as evidenced by the large numberof icons 710 depicting a police unit's comprehensive patrol overvirtually the entirety of a large island part of the region 720. Ofcourse, in at least one embodiment, icons illustrating the movement ofmore than one such response vehicle may be simultaneously displayed insimilar fashion in the aerial view 700.

In an embodiment, in response to user selection of an icon 710, thevelocity and bearing of the vehicle at the time associated with theselected icon is displayed in the aerial view 700. Additionally, theelectronic history may further comprise identifiers of dispatch callsreceived by one or more of the emergency response vehicles.Consequently, an icon 730 may be displayed in the aerial view 700illustrating a geographic location of the response vehicle at a timethat the response vehicle received a dispatch call.

FIG. 4 illustrates a process 400, according to an embodiment of theinvention, for tracking a set of at least one emergency serviceprovider. The process 400 is illustrated as a set of operations shown asdiscrete blocks. One or more steps of the process 400 may be implementedin any suitable hardware, software, including instructions embodiedwithin components, firmware, or combination thereof. The order in whichthe operations associated with the process 400 are described is not tobe necessarily construed as a limitation.

At a block 410, an electronic history is compiled. The electronichistory includes at least one identifier of a service provider, at leastone identifier of an event to which the service provider responded, andGPS data identifying the geographic location of each service provider ateach time interval within the duration of the event. The event is of afinite duration. For example, the client device 210, server 230 and/orcomputer system 260 may regularly (e.g., every five seconds or otherpredetermined time interval) receive, via network 220 or otherconventional means, AVL data from transmitters in a set of emergencyresponse vehicles and correlate this data with respective identifiers ofthese response vehicles and identifiers of and information associatedwith emergency-response events to which such vehicles responded. Theidentifiers of these response vehicles and identifiers of andinformation associated with emergency-response events may be stored indatabase 240 and/or a memory device associated with client device 210.The AVL data will typically take the form of a latitude/longitudeposition of the response vehicle and the time at which such vehicle isin such position. Consequently, the electronic history that thiscorrelative activity yields is configured to enable a processing deviceto determine the geographic location of a given response vehicle at, forexample, five-second intervals within the duration of an event.Additionally, the information stored in database 240 and/or clientdevice 210 may further enable the inclusion in the electronic history ofdata identifying the geographic location of a given response vehicle attime intervals occurring prior and/or subsequent to the duration of theevent. This latter feature may be implemented by, for example, employingthe process 300 described above.

At a block 420, the electronic history is stored in a memory device. Forexample, once the position and event data has been correlated with theservice provider identifiers to yield the electronic history, suchhistory is stored in the database 240, for example.

At a block 430, a user interface is generated to a display device withinwhich is displayed a first identifier of a first event of the set of atleast one event. For example, and referring to FIG. 8, the client device210 may generate to the display 250 a menu 800 populated withuser-selectable identifiers 810 of events to which response vehicles,for which viewable tracking is available, responded. For each identifier810, the menu 800 may further display a description 820 of the event,the address 830 of the event, identifiers 840 of the response vehiclesresponding to the event and identifiers 850 of the date/time of theevent.

At a block 440, a selection of the first event identifier is receivedfrom a user via the user interface. For example, and again referring toFIG. 8, using a conventional pointer device (not shown), the user mayselect an identifier 810 of an event to which response vehicles, forwhich viewable tracking is available, responded.

At a block 450, in response to the selection of the first eventidentifier, an aerial view of a geographic region within which the firstevent took place is generated to a display device. For example, uponreceiving a selection of identifier 810 and, consequently, a selectionof an event of interest, the client device 210 may access the database240, or other memory device, in which the electronic history is stored.From the electronic history, the client device 210 can determine thegeographic region in which the selected event took place. Subsequently,the client device 210 can, in a conventional manner, generate to display250 a rendering of the determined geographic region using aerial mapdata, for example, that may be stored in database 240 or on the clientdevice itself.

At a block 460, at least one icon representing at least one respondingservice provider at the geographic location corresponding to at leastone time interval within the duration of the event is displayed in theaerial view. For example, as illustrated in FIG. 9, two responsevehicles responded to the event selected from menu 800. Consequently,depending on the number of time intervals selected by the user forviewing, two sets of one or more icons 910, 911 illustrating therespective activity of the two response vehicles in transit to andarriving at the scene of the event are superimposed on the renderedgeographic region 920 determined at block 450.

In an embodiment, in response to user selection of an icon 910, 911, thevelocity and bearing of the vehicle at the time associated with theselected icon is displayed in the aerial view 900. Additionally, theelectronic history may further comprise identifiers of dispatch callsreceived by one or more of the emergency response vehicles, as well asidentifiers of one or more event locations to which such responsevehicles travel in response to a dispatch call. Consequently, a callicon 930 may be displayed in the aerial view 900 illustrating ageographic location of one or more of the response vehicles at a timethat such response vehicle received a dispatch call. Similarly, an eventicon 940 may be displayed in the aerial view 900 illustrating the eventlocation(s) to which such response vehicles traveled in response to adispatch call. In an embodiment, a selection of the event icon 940 bythe user may cause information about the event, such as the address ofthe event, time of event, the type of event, etc. to be displayed in theaerial view 900.

FIG. 5 illustrates a process 500, according to an embodiment of theinvention. The process 500 is illustrated as a set of operations shownas discrete blocks. One or more steps of the process 500 may beimplemented in any suitable hardware, software, including instructionsembodied within components, firmware, or combination thereof. The orderin which the operations associated with the process 500 are described isnot to be necessarily construed as a limitation.

At a block 510, identification information for at least one serviceprovider is obtained. For example, identifiers of emergency responsevehicles, identical or similar to those discussed above with referenceto process 300, for example, may be stored in, and accessible by server230 and/or client device 210 from, database 240 and/or a memory deviceassociated with the client device.

At a block 520, location information for the at least one serviceprovider is obtained. For example, the client device 210, server 230and/or computer system 260 may regularly (e.g., every five seconds orother predetermined time interval) receive, via network 220 or otherconventional means, AVL data from transmitters in a set of emergencyresponse vehicles and correlate this data with respective identifiers ofthese response vehicles that are stored in database 240 and/or clientdevice 210. Such data will typically take the form of alatitude/longitude position of the response vehicle and the time atwhich such vehicle is in such position.

At a block 530, data is obtained enabling the generation to a displaydevice of an aerial view of a geographic region in which the locationinformation indicates the at least one service provider has been intransit. For example, the client device 210 can determine, based on theidentification information and/or location information, the geographicregion(s) in which a selected response vehicle was located during agiven time period or, for example, a user-selected time period ofinterest. Subsequently, the client device 210 can, in a conventionalmanner, generate to display 250 a rendering of the determined geographicregion(s) using aerial map data, for example, that may be stored indatabase 240 or on the client device itself.

At a block 540, the map information is displayed overlaid with ananimated rendering of the movement of the at least one service providerwithin the geographic region. For example, as illustrated in FIG. 10,the activity of a selected response vehicle is superimposed as a “slugtrail” 1010 on the rendered geographic region 1020 determined at block530. In an embodiment, the brighter and thicker the slug trail, the morefrequently the unit drove along that particular stretch of road.

In one aspect, a system, referred to herein as Real-Time Agency ActivityDisplay and Reporting (RAADAR), is described. RAADAR is a system and/orsoftware designed to provide near real-time information for FirstResponders (Police and Fire) about the nature of the calls they areassigned to. RAADAR can provide more information than is communicatedover the radio, including notes from 911 call receivers, maps, aerialimagery, automatic vehicle location and building safety information.

In some aspects, RAADAR may be a custom web-based tool designed for realtime or near-real time display of information relating to active 911calls, for example, for or across a number of different member agencies.An important aspect of RAADAR, as distinguished from prior systems, isthat it can provide users real-time updates to 911 calls in progress.

Use of RAADAR may require a user to have a valid login into the website. RAADAR does not allow users to self-register; users need to bepre-approved by agency administrative staff before they are given accessto RAADAR. Once a user has a valid RAADAR login, they are able to seeactive 911 calls for the agencies they have been given permission toview. RAADAR offers per-agency filtering on a per-user basis so that auser can see some, all or none of member agencies. Users can also befiltered between Police and Fire so that they do not see calls from theother discipline.

Once in RAADAR, calls can be opened and more details seen. Detailsinclude the unit(s) assigned to the call, their status, a map of thecall location and where the units assigned to the call are at and ascrolling list of comments from 911 call receivers and dispatchers.Static information is also displayed that can include PrePlaninformation (building safety for fire personnel), Response Planinformation (resource assignments for fire agencies), caution notes,location name, address, person name, phone number, latitude andlongitude. RAADAR also has a Call Search feature that allows users tosearch for calls on a number of criteria.

RAADAR may include a software application, for example, created orprogrammed using Microsoft ASP .NET and Visual C# programming languages.The application may run as a custom web site that is available to anyonewith a valid login and an Internet connection. In some cases, RAADAR maybe designed specifically to be run as a web site. The preferredapplication is to run RAADAR on a Microsoft Windows Server usingInternet Information Services to serve end users.

In one aspect, RAADAR consists of many Active Server Pages (ASP) andcustom computer executable code libraries (e.g., totaling 32,975 linesof C# code). Version Control may, in some cases, be maintained withMicrosoft's Team Foundation Server. RAADAR's functionality is driven bycustom code libraries. Some of the functions of these libraries includethe following.

RAADAR can independently connect to 25 different databases on 15distinct Microsoft SQL database servers. Custom libraries may retrievethe data and convert it to a common format for display to the end user.

The described system can create on-the-fly active server pages todisplay the data to the end user. The described system can connect to aWindows File server to retrieve saved audio files (911 call and radioaudio). The saved audio files can be converted to MP3 files via anothercustom library before they are downloaded to the end user.

The described system can connect to the Tyler Mobile Server to retrieveXML files associated with Mobile Field Reports. These files are parsedand appropriate data is displayed to the end user in the form of a SAPCrystal Report. Additional code in RAADAR enables the Crystal Report tobe saved as an Excel spreadsheet or PDF document. A code library mayconnect to the Snohomish County Emergency Radio System (SERS) and sendspages to specified SERS.

Custom libraries enable the end user to search for calls on a variety ofdifferent criteria (partial address, agency, call type, date range,etc.). Libraries can be used to control what features of RAADAR userssee. There are many roles defined for users; each role allows themaccess to a different feature in RAADAR. Custom libraries also connectto external agencies, and can retrieve call data and integrate itseamlessly into the user interface. Custom libraries can also retrieveunit AVL data and format it into a file suitable for displaying inGoogle Earth, or other mapping or similar visualization application.This file is downloaded to the end user and can be used for severalpurposes, such as to evaluate where a given unit was during a certaintimeframe, observing the routes taken by emergency services personnel toan incident, evaluating patrol patterns to determine if neighborhoods ina jurisdiction are being adequately covered, or for incident commandersensuring that a perimeter has been adequately set up or if moreresources are needed. Custom libraries can also be used also determinewhich live stream to connect to on a given call if a user is authorizedto listen to real time radio traffic.

Specific features of RAADAR include utilizing Ajax technology to onlyrefresh parts of web pages that have changed. This results in incrediblyfast refreshes of information displayed by RAADAR.

RAADAR can display all calls being dispatched by a 911 center regardlessof CAD system in use, such that two CAD systems nay be in use from twodifferent vendors (Tyler Technologies and TriTech Systems). Both CADsystems are highly dissimilar in look-and-feel, functionality andpurpose. Further, each CAD's database architecture is vastly differentand incompatible with each other. RAADAR is able to gather data fromboth CAD systems and display it in the same user interface to the enduser. The end user does not know that there are two different CADsystems—the only difference the end user sees is color-scheme changesfor police vs. fire incidents.

RAADAR also has the ability to generate KML files from AVL (AutomaticVehicle Location) data which can be displayed in Google Earth. This KMLdata is also animated so command staff can evaluate the routes taking byFirst Responders enroute to an incident. Other uses for the KML fileswould be to evaluate patrol patterns in a givenneighborhood/district/patrol shift. Patterns can be evaluated to see ifpatrols should be increased in a given area or if patrols are evenlydistributed across their assigned area.

In some aspects, RAADAR may be enhanced to include real-time radiotraffic. This allows agency command staff the ability to listen to radiotraffic outside of the 800 MHz coverage area. Command staff that are notinvolved in the incident can now listen to radio traffic and be informedof actions by field personnel as they happen.

In addition, a new enhancement to RAADAR allows it to link to recordingsof the 911 call and radio traffic associated with an incident. Thisgives Public Records staff and agency prosecutors instant access torecordings without requiring using a separate application to search forthe recordings in question.

In some aspects, one or more of the features described herein may beused in conjunction with one or more aspects of the system andtechniques describe in related U.S. patent application Ser. No.14/213,995, which is included at the end of this application. Thefeatures described herein may integrate with, utilize various aspectsof, or in essence run on top of or in addition to the systems describedin U.S. patent application Ser. No. 14/213,995.

The described systems and software may provide real-time information toFirst Responders in a unified format regardless of the Computer-AidedDispatch (CAD) system used by the 911 dispatch center. RAADAR gathersCAD data directly from databases and presents it to the end user in aunified user interface. RAADAR may provide First Responders moreinformation about the nature of 911 calls and events they are respondingto. This information goes beyond what can be transmitted over the radioand includes notes from the call receiver (information gathered from theindividual calling 911), maps, aerial imagery, automatic vehiclelocation, vehicle mapping, agency resource status, and numerousreporting tools.

TriTech Systems has a similar product named Visinet. Visinet does notprovide the same level of real-time information, does not updateautomatically, and does not integrate data from disparate CAD systems.However, TriTech Visinet Web Browser does not meet the same purpose asRAADAR. Visinet is more of a reporting tool for after-incident usewhereas RAADAR is targeted at getting information to users in real-time.

Tyler Technologies also has a similar product named CAD WebView. It is abasic web interface that provides minimal information to end users. CADWebView appears to be more of a porting of Tyler's Aegis Mobile softwareapplication to a web format. CAD WebView also is not able to aggregateCAD data from disparate sources and display it in a common userinterface. However, Tyler's CAD WebView has relied on a third-partydisplay tool that is unstable and buggy. During testing and evaluationof CAD WebView in 2011, users found it to be unstable, limited, andultimately unusable. Issues cited included disliking the user interfaceand hard-coded limits on searching in addition to instability problems.

Features according to one or more embodiments may include the following:

Police and Fire Reports and Redaction

Feature set capability allows users to pull up active call information.Additional capability allows user to pull a pre-formatted report of thecall or provide a redacted report for public records requests, whichstrips the call of all protected or personal data not eligible forpublic records requests.

Agency Paging Capabilities

Feature set capability allows RAADAR to integrate paging logs (FIG. 11),manual and group paging (FIG. 12) capabilities within RAADAR to reportpages sent from RAADAR and to send mass notification to emergencyservices personnel from RAADAR. Paging groups are predefined based onagency and organizational need and access security is provided throughRAADAR application layer security.

Active Call to Active 911 Phone and Radio Recording Capability

Feature set capability allows RAADAR to pull active call, in-progresscall information and link call to voice and radio information related tothe call (FIG. 13). The enhancement enables users, administrativereview, prosecutor review, and public records specialists the capabilityto use RAADAR to collect call information in one place. RAADAR linksCAD/911 information to another system which logs all voice and radiotraffic specific to the incident event.

Active Call and Live Streaming Radio

Feature set capability allows RAADAR to stream audio traffic from liveradio events through the integration of trunk tracking scanner hardwaredirectly connected to a server which RAADAR can access (FIG. 14). A“live” 911 call or incident can be tracked and radio traffic to thefield units can be listened to via internet and monitored “live” as theevent is occurring, while also monitoring field and dispatch notes viaRAADAR interface and unit history reporting.

Link to Fire Response Plans

Allows RAADAR to display a link to the Fire Agency Response Plans for agiven address. A “live” 911 call or incident can be tracked by units inthe field and a response plan can be viewed by incident commandersshowing what resources a given problem nature requires (FIGS. 15A and15B).

Link to PrePlan Documents

RAADAR includes a link to the Fire Agency Response PrePlan document(s)for a given address. A “live” 911 call or incident can be tracked byunits in the field and a building safety plan can be viewed by incidentcommanders (FIGS. 16A and 16B).

Current Traffic Report

RAADAR links to the WSDOT web site to display the latest traffic map forarea freeways. This allows first responders to choose the best route toa given location e.g. medic unit transporting to Level 1 Trauma Center(FIGS. 17A and 17B).

Zone 1 Resource Availability

From a single page in RAADAR, fire agency command staff can get a quickoverview of resource allocation across a zone. This may includedisplaying units that are in quarters, have been moved up to anotherstation to provide coverage, are out of service or are assigned to anincident (FIGS. 18A and 18B).

Mobile Report Viewer

RAADAR allows Police Records Staff to see field reports being created bypatrol staff. This allows Records Staff and Crime Analysts to see fieldreports as they are being worked on from any computer (FIGS. 19A and19B).

Chat Audit

Allows supervisory staff to review chat messages sent betweendispatchers and/or mobile field units (FIG. 20).

Call Alerts

RAADAR checks for active alerts associated with a given Call forService. If RAADAR finds an active Order of Protection, Officer Safetyor Stolen Vehicle alert, an appropriate button will appear in the CallDetails page as illustrated in FIG. 21.

Clicking on the button will display the text of the alert as illustratedin FIG. 22.

Electronic Personnel Accountability Safety System (ePASS)

The implementation of ePASS in RAADAR is meant to enhance informationavailable to Fire Agency Incident Commanders and is a replacement for amanual system consisting of Velcro radio ID numbers and apparatusdesignators.

Personnel Profile

A new Personnel Profile page has been created in RAADAR to trackinformation related to the position the fire personnel holds. Theseinclude assigned RadioIDs, pager(s), rank and certifications asillustrated in FIG. 23.

Passport Radio Assignments

The designated ePASS officer is able to assign radio IDs and personnelto the various positions on a given apparatus.

From the Radio Assignments page, the officer first selects the firestation he's working at. The stations are filtered to only display theofficer's home agency stations (e.g., a Shoreline FD user will not seeBellevue FD stations) as illustrated in FIG. 24.

Next, he selects the apparatus to assign personnel to as illustrated inFIG. 25.

By clicking on one of the Radio ID entries, a new window opens upallowing the officer to modify the assignment as illustrated in FIG. 26.

The Personnel drop-down is filtered to agency personnel. Radio IDs canbe changed from this page and will be saved in the database asillustrated in FIG. 27.

Incident Command

A new Incident Command page is available to designated agency IncidentCommanders. Typically, these are Battalion Chiefs.

From the Call Details page, the Commander clicks the Incident Commandbutton to access the Incident Command page as illustrated in FIG. 28.

The Incident Command page includes two timers—Call Timer whichcalculates the elapsed time since the call was created in CAD and 1stOnScene Timer which calculates the elapsed time since the first unitarrived on scene.

The address of the incident is prominently displayed at the top of thepage. Below that are the Resource Passports. These are displayed foreach unit assigned to the call as illustrated in FIG. 29.

Resource Passports

The Resource Passports are dynamically added/removed from the page basedon resources assigned to the incident. The passports are color-coded andsorted by apparatus type: First are Engines, followed by Ladders/LightForce, Battalion Chiefs, Medics, MSO, Aid and finally other supportresources. The bottom of the passport is color-coded based on the unit'sstatus (Dispatched/En Route/At Scene/Transporting). A further sort isdone in each classification of unit based on the CAD-calculated ETA.

Clicking on the Apparatus Name will expand the passport to reveal theRadio IDs and personnel assigned to the apparatus as illustrated in FIG.30.

Note that the passport will automatically contract back to the compactdisplay after 30 seconds.

Call Narratives

These are the narratives as entered by call receivers and/or dispatchersat NORCOM. This list updates in near real-time and the newest entriesare on top.

Emergency Radio Activations

RAADAR is constantly watching for a CAD narrative entry indicating wehave received an Emergency Radio Activation from one of the radiosassociated with personnel assigned to the incident. If an emergencyactivation is detected, an alert flashes on the Incident Command page asillustrated in FIG. 31.

By clicking the Acknowledge button, the alert is acknowledged and loggedalong with the timestamp of the acknowledgement. The alert no longerdisplays after it has been acknowledged.

Apparatus Profile

Individual apparatus profiles can also be edited from within RAADAR. Thefirst step is to have the apparatus added to the ePASS role. When addedto the ePASS role, the apparatus user now has the ePASS sub menu underthe Profile menu as illustrated in FIG. 32.

Pager(s):

Clicking in this grid allows you to edit the pager informationassociated with the apparatus.

Mobile Radio(s):

Clicking this grid allows the mobile radio ID to be edited. It is alsopossible to add multiple mobiles to an apparatus, where appropriate(e.g. Light Force).

Other Radios:

This grid allows you to edit the position name and associated Radio IDon a given apparatus. You can also click the Add New Radio button tocreate another radio position on the apparatus.

TriTech/Central Square InformCAD Integration

The information saved on the ePASS Personnel Profile page as well as theradio assignments are also saved in InformCAD. This allows the FireDispatchers to have the same information available to them in CAD thatthe incident commanders have in RAADAR.

Profile Settings

A new page has been added to RAADAR to enable the end-user to managetheir profiles. Users are able to update their E-mail address and selecta list of agencies to display in RAADAR based on the agencies they havebeen assigned permission to view as illustrated in FIG. 33.

An embodiment provides the ability to automate through software thetranslation of disparate field names (e.g., “domestic violence,”“robbery,” “burglary,” etc.) and/or acronyms for such names into acommon format. An embodiment of the invention includes a method toachieve consistency through a software product utilizing proprietarysoftware technology within the RAADAR software. One or more embodimentsof the invention have applications throughout all commercialapplications where multiple vendors exist to accomplish similar taskswithin databases, fields or tables, but utilize proprietary field namesor dissimilar naming conventions to accomplish tasks. An embodimentutilizes dissimilar and disparate CAD systems to join like data toachieve a common format and name translation. However, this translationhas application in any industry or software application including publicsafety, systems shared among jurisdictions or numerous otherapplications.

An embodiment allows users of the RAADAR software to perform callsearches across multiple Public Safety Answering Points (PSAPs) each ofwhich may use a different role CAD software system. When a user definesa call search in RAADAR, the software tests to see if the user isselecting agencies that span multiple PSAPs. If so, the call-typestranslation table is utilized which allows the user to searchgeneralized call types. These generalized call types are thendynamically translated into the actual call type in use at the PSAPbeing searched.

An embodiment of the invention, which may be referred to herein as the“RAADAR translation table,” dynamically translates a common name intothe name(s) in use at a PSAP. For instance: “Domestic Violence” at onePSAP may be “DVP” at another or “DV VERBAL” at yet another. RAADARtranslation table once connected to systems takes those three field-namevariations and translates it into a common unified format within RAADARto “Domestic Violence.” An approach according to an embodiment isunified, understanding each vendor, customer, solution is different butstreamlining common operations into the unified shared approach acrossdissimilar vendors and customers.

A method according to an embodiment is as follows. As shown in FIG. 34,a user can initiate a new Call Search within a user interface 3400generated by the RAADAR system. The user selects from a menu 3410agency/agencies to search. An embodiment consults a memory to checkwhether the selected agencies belong to one or more PSAPs. If theselected agencies belong to more than one PSAP, the translation table isconsulted, and the respective Call-Type codes used by those agencies arepresented to the user as a generic code. When the user submits thesearch, the translation table is used to translate the generic call typeto the PSAP-specific call type(s) for the agency being searched. Notethat a generic call type may translate into more than one call type atany given PSAP.

Features of one or more embodiments include the following:

A SQL database table that contains a column for the generic call types,then one column for each PSAP containing the corresponding specific calltype(s). The PSAP column may contain textual or numeric representationsof call types, depending on the CAD software system in use at a givenPSAP.

C# code in an embodiment that tests whether multiple PSAPs are beingsearched.

C# code that utilizes the translation table to convert to the nativecall type in use at a given PSAP.

Taking a generic call type and translating it into a specific call typein use in a given software application.

Translating a specific call type into a more generic version.

Dynamically translating specific, disparate call types into genericversions for consistency.

Referring to the screenshot illustrated in FIG. 34, an embodiment allowsRAADAR to search for a common, generic call type across multiple PSAPs.When a user first navigates to the Call Search interface 3400, thePriority 3420 and Call Type 3430 lists are populated based on the user's“home” agency.

Referring to the screenshot illustrated in FIG. 35, an embodiment allowsa user to select from the menu 3410 of Call Search interface 3400 two ormore agencies that reside in more than one PSAP. The screen mayautomatically update to hide the Priority list 3420 (not all PSAPsutilize priorities) and populate the Call Type list 3430 with genericcall-type codes corresponding to the Call-Type codes specific to theselected two or more agencies.

Referring to the screenshot illustrated in FIG. 36, an embodiment allowsa user to, for example, search for all traffic-type calls in apredetermined time interval such as, for example, the past week. Asillustrated in FIG. 36, the selection of the generic call-type code of“Traffic” from Call Type list 3430 has retrieved call entries associatedwith Call-Type codes “T”, “TRAFFIC STOP” and “Traffic General” used bythree different PSAPs: NORCOM (BLVPD), Bothell (BPD) and Sno911 (BRIER).

One or more embodiments provide software development enhancement toautomate through software the display of heat maps graphically depictingemergency-service-provider incident data. One or more embodimentsprovide a method to dynamically produce a heat map from the results ofany Cleared Call Search within the company's RAADAR softwareapplication. One or more embodiments enable any public safety agency toproduce heat maps of incident data “on the fly” enabling a greater levelof statistical analysis than was previously available. Public SafetyAgencies without dedicated analysis staff can now produce maps showingconcentrations of various public safety events. One or more embodimentsof the invention take the results of a Cleared Call Search performed inRAADAR and dynamically generates a heat map. This heat map depicts wherethe incidents are located and whether there are concentrations ofincidents in any given area. RAADAR further enhances this feature byenabling the user to search neighboring jurisdictions to get broadersituational awareness.

A method according to an embodiment is as follows: a user initiates anew Call Search within using the Call Search interface 3400. The userselects agency/agencies using menu 3410, call type(s) using Call Typelist 3430 and/or date range(s) using alphanumeric entry fields 3440 tosearch. RAADAR performs the call search and saves the results to atemporary XML file stored on the RAADAR server. The user clicks a“Generate Heatmap” button. RAADAR utilizes the information in the XMLfile to generate a heat map which may then be displayed in a new webbrowser tab. Each call may be graphed as a black dot or other indicatorin the heat map. The black dot can be clicked and a popup window willappear displaying details of the call (call date/time, call type,agency, etc.).

Features of one or more embodiments include the following:

RAADAR code directs it to save a copy of any cleared call search resultto an XML file on the RAADAR server.

After the XML data file is saved, an XML schema file is saved thatdescribes the format of the XML data file.

The name of the XML file is randomly generated and saved in anon-displayed column in the call search results grid.

When the Generate Heatmap button is clicked, C# code is executed thatretrieves the file name, reads the contents of the XML file, formats itinto the proper syntax for heat maps and generates the heat map.

Dynamically generating a heat map from call search results.

Dynamically generating a heat map utilizing a base map (e.g., Google,Bing Maps, ESRI ArcGIS, OpenStreetMap, etc.) from call search results.

Dynamically generating a heat map from other search results.

Referring to the screenshot illustrated in FIG. 37, a user can, forexample, use the Call Search Interface 3400 to search for all TrafficAccidents (in the illustrated example by selecting the code “TA” fromthe Call Type list 3430) for a selected time period (the month of August2019) for Bellevue Police (selection of “BLVPD” in menu 3410).

Referring to the screenshot illustrated in FIG. 38, such a searchresults in the display of multiple call entries matching the searchparameters. By clicking on the Generate Heatmap button 3800 shown inFIG. 38, a new window, illustrated in FIG. 39, opens with all of thecalls displayed in FIG. 38 mapped as a heat map 3900 of the aeriallocation in which the incidents associated with the displayed callentries took place. Each such incident may be indicated by a black dot3910 representing an individual call (or traffic accident, in thisillustrated example). Differently colored areas, for example, of theheat map each indicate a respectively different correspondingconcentration of accidents in the selected time period.

The black dots 3910 can be clicked, which, as is illustrated in FIG. 40,will open a window 4000 showing information pertaining to thecorresponding call/incident.

One or more embodiments may include a software enhancement to acompany's RAADAR application that automatically connects to the correctPublic Safety Answering Point (PSAP) in cases of mutual aid calls. Oneor more embodiments provide a method to automatically connect to thePSAP requesting mutual aid from a neighboring jurisdiction. One or moreembodiments provide first responders dispatched on a mutual aid call theability to see the call details directly from the originating PSAPregardless of the Computer-Aided Dispatch (CAD) software application inuse. This untethers the end user from their own CAD vendor and allowsthem access into disparate CAD systems. Such embodiments increasesituational awareness for first responders.

One or more embodiments provide first responders more detailedinformation when assigned to a mutual aid call. These calls are when aneighboring jurisdiction that is served by another PSAP asks foradditional resources to respond to a call for service. When the firstresponder opens up the Mutual Aid call in RAADAR, the call details areautomatically retrieved from the originating PSAP that is different fromthe home PSAP the first responder is dispatched from.

A method according to an embodiment is as follows: A first responderlogged into RAADAR is dispatched on a Mutual Aid call. The firstresponder opens the call in RAADAR to see the call details. RAADARdetects that the call is Mutual Aid and determines what the originatingPSAP is, connects to that PSAP and retrieves the call details. RAADARdisplays the call details from the originating PSAP to the firstresponders.

Features of one or more embodiments include the following:

C# code and logic that determines when a call is Mutual Aid, what thesource PSAP is, and instructions for connecting to that PSAP andretrieving the unique Call ID associated with the incident.

RAADAR then redirects the user's screen to retrieve the incident detailsfrom the originating PSAP.

Viewing call details within the RAADAR application.

Referring now to the screenshot of FIGS. 41A and 41B, call (CFS) number974 as denoted by the circle and reference numeral 4100 is a Mutual AidRequest for emergency-response unit vehicle A195. The address is listedas “0* DISPATCHER WILL GIVE ADDRESS.” Prior to an embodiment of thisinvention, the aid crew of A195 would have to be told over the radiowhat they were to do and where they were going. They would also have tolook up the address on their own in a maps application to get drivingdirections. An embodiment of the invention detects that the call is aMutual Aid Request and includes logic to determine what PSAP the calloriginated in. When the user clicks on this CFS 974 entry, the user isautomatically redirected to the call from the originating PSAP's CADsystem. This contains more detailed information including callnarratives, which other units have been dispatched, the radio channeland a hyperlinked address that will open a map as illustrated in FIG. 43in a new window that is centered on the reported address. In the exampleillustrated in the screenshot of FIG. 42, the call details have beenretrieved from agency Sno911. In FIG. 43, NORCOM A195 is denoted as“KCA195”—the two-letter prefix indicating it's a King County unit.

While the preferred embodiment of the invention has been illustrated anddescribed, as noted above, many changes can be made without departingfrom the spirit and scope of the invention. For example, at least oneembodiment described above herein may be implemented in connection withFire and EMS units, in addition to the Police units discussed in theillustrated examples. Additionally, at least one embodiment describedabove herein may be implemented with respect to non-emergency serviceproviders, such as mail and package delivery, grocery delivery, andlarge-scale transportation operations such as shipping and airlines. Anembodiment may include GIS layers, for example, that enable theplacement in the aerial view 700, 900 of police and fire stationlocations, as well as fire response areas and police beats. In anembodiment, icons representing the station locations, response areas andor beats may be selected by user, in response to which iconsrepresenting movement of all units associated with suchlocations/areas/beats may be automatically shown in the aerial view 700,900. Additionally, clicking on any of the icons representing a responseunit may open up a window, for example, indicating the unit's call sign,their location, and the timestamp of that particular AVL plot.Additionally, an embodiment may include animation controls associatedwith the aerial view 700, 900 enabling a user to control the speed atwhich the icons representing response vehicles are sequentially placedin the aerial view to illustrate the movement of the corresponding unit.These controls also enable the user to control the length of the icon“vector” (i.e., the number of icons shown at any given time toillustrate movement of the corresponding vehicle) during the animationwithin the aerial view 700, 900. Moreover, the electronic historiesdescribed above may be processed in such a manner as to allow the userto view movement of a vehicle in “near real-time” in the aerial view700, 900. Accordingly, the scope of the invention is not limited by thedisclosure of the preferred embodiment. Instead, the invention should bedetermined entirely by reference to the claims that follow.

The embodiments of the invention in which an exclusive property orprivilege is claimed are defined as follows:
 1. At least onecomputer-readable medium including instructions that, when executed byat least one processing device, enable the at least one processingdevice to perform a method, the method comprising the steps of:accessing over a network first and second computer-aided dispatchdatabases, the first database having a first database identifier andincluding a first data set having a first data-set identifier, thesecond database having a second database identifier and including asecond data set having a second data-set identifier different from thefirst data-set identifier, each of the first and second data setscharacterizing at least one response to at least one incident by atleast one emergency response vehicle; retrieving from the first andsecond computer-aided dispatch databases the first and second databaseidentifiers and first and second data-set identifiers over the networkfrom the first and second databases; generating a third data-setidentifier based on the first and second data-set identifiers anddifferent from the first and second data-set identifiers; presenting ona display device the first and second database identifiers in agraphical user interface (GUI); in response to receiving a selection ofthe first and second database identifiers from a user, displaying thethird data-set identifier in the GUI; in response to receiving aselection of the third data-set identifier from the user, retrievingover the network from the first and second databases the first andsecond data sets; and displaying the first and second datasets in theGUI.
 2. The method of claim 1, wherein the set of at least one serviceprovider comprises a police unit.
 3. The method of claim 1, furthercomprising displaying the first and second data-set identifiers in theGUI.
 4. The method of claim 1, further comprising displaying the firstand second database identifiers in the GUI.
 5. The method of claim 1,wherein the third data-set identifier is generated in response toreceiving a selection of the first and second database identifiers fromthe user.
 6. At least one computer-readable medium includinginstructions that, when executed by at least one processing device,enable the at least one processing device to perform a method, themethod comprising the steps of: retrieving over a network a data setcomprising: (a) identifiers of a set of incidents occurring within adefined geographic region to which at least one service providerresponded during a first time period and (b) address data identifying alocation within the geographic region of each said incident of the set;receiving from a user, via a user interface generated to a displaydevice, an instruction to generate a heat map of the incidents occurringwithin the geographic region during the first time period; in responseto the instruction to generate the heat map, converting the address datato GPS data; generating a heat map of an aerial view of the geographicregion based on the GPS data; and displaying to the display device theheat map in a user interface.
 7. The method of claim 6, furthercomprising generating to the display device a user interface withinwhich is displayed the identifiers.
 8. The method of claim 6, whereinthe set of at least one service provider comprises a police unit.
 9. Themethod of claim 6, further comprising: receiving from the user, via theuser interface, a selection of an icon identifying a location within thegeographic region of an incident of the set; and in response to saiduser selection of the icon, displaying in the user interface informationcharacterizing the incident associated with the selected icon.
 10. Atleast one computer-readable medium including instructions that, whenexecuted by at least one processing device, enable the at least oneprocessing device to perform a method, the method comprising the stepsof: accessing over a network first and second computer-aided dispatchdatabases, the first database having a first database identifier, thesecond database having a second database identifier; identifying thefirst and second databases using the first database identifier andsecond database identifier respectively; providing from the seconddatabase to the first database a mutual-aid request for first respondersto respond to an incident; generating to a graphical user interfaceavailable to the first responders an identifier of the mutual-aidrequest; in response to selection of the identifier by the firstresponders, retrieving from the second database and displaying to thegraphical user interface information characterizing the incident, theinformation including a link to a map that provides an aerial view ofthe location of the incident to the first responders.
 11. The method ofclaim 1, wherein the first responders comprise a police unit.